home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / dos_win / winsock / maillist / 94-02.Z / 94-02 / text0226.txt < prev    next >
Encoding:
Text File  |  1994-02-28  |  2.2 KB  |  48 lines
  1.  
  2.  >> 
  3.  >> My problem, again, isn't with actual crashes.  It is with lost connections
  4.  >> that "die" for long periods of time, with long being defined as 1 sec < x <
  5.  >> 10 minutes.  Note that ANOTHER session continues just fine.  That is, I can 
  6.  >> have a Telnet hang, and open a second one -- which may or may not hang.  The 
  7.  >> first hung one wille eventually pick back up.  The second one will eventually 
  8.  >> hang up too, but it will also eventually start working again.  While either
  9.  >> or both of these are hung I can open an FTP, and that will also work --
  10.  >> and all three apps will then run at some point.  But they will also all
  11.  >> show the "pause" problem eventually, with QVT telnets being hit the worst.
  12.  >> 
  13.  >> The same use pattern on a MAC with InterSLIP or MAC/PPP operates perfectly.
  14.  >> 
  15.  >> This is pretty clearly a stack and/or SLIP driver problem.
  16.  >> 
  17. You know..I hate to interject a technical not or two in the flame-fest but
  18. your problem description quite accurately describes a TCP stack which is
  19. either resource starved or is going to a poorly designed or buggy TCP
  20. back-off algorithm.  Of course you could be fighting a poorly designed
  21. silly-window avoidance algorithm also, but thats unlikely.
  22.  
  23. Your problem is occuring either
  24. *    because all available resources (buffers) in the system are
  25.         consumed by another session, an improperly sized send-side
  26.         TCP window or a slew of incoming data that hasn't been processed
  27.     by an app.
  28. *       your TCP loses a packet (bad checksum, dropped packet, whatever),
  29.     the sender waits for a period of time, retransmits.  For some
  30.     reason (improper buffer scavenging at a guess) your side doesn't
  31.     receive the resend; the sender waits longer before resending and
  32.     away you go.
  33.  
  34. I would have a look at the network traffic using a Lanwatch,Sniffer,
  35. Lanalyser or the tool of choice.
  36.         
  37. Shareware and freeware are good things; but at some point you probably
  38. want a commercially designed and supported IP stack.  Given your
  39. way with criticism over the years(:-) :-)) perhaps I should recommend
  40. one of our competitors. On the other hand perhaps you ought to try ours
  41. and complain about it until it meets your needs.  That certainly would
  42. force us to up the bar a bit :-).
  43.  
  44.  
  45. Larry Backman
  46. FTP Software
  47.  
  48.